home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group02b.txt / 000072_icon-group-sender_Mon Oct 14 12:48:25 2002.msg < prev    next >
Internet Message Format  |  2003-01-02  |  4KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9EJm2k26263
  4.     for icon-group-addresses; Mon, 14 Oct 2002 12:48:02 -0700 (MST)
  5. Message-Id: <200210141948.g9EJm2k26263@baskerville.CS.Arizona.EDU>
  6. From: Art Eschenlauer <art.eschenlauer@sufsys.com>
  7. To: icon-group@cs.arizona.edu
  8. Cc: "'ahamm@mail.com'" <ahamm@mail.com>,
  9.    "'Shmuel (Seymour J.) Metz'"
  10.      <spamtrap@library.lspace.org.invalid>
  11. Subject: Heat, light, Idol, and Unicon (RE: Icon Wish List)
  12. Date: Mon, 14 Oct 2002 10:32:29 -0500
  13. Errors-To: icon-group-errors@cs.arizona.edu
  14. Status: RO
  15.  
  16. I am not quite sure why there is so much talk devoted in this thread to
  17. adding object orientation to Icon.  Idol has been around for a long time,
  18. and Unicon
  19.   <http://unicon.sourceforge.net>
  20. (which is in beta) extends Idol by integrating many of its features into a
  21. gently extended dialect of Icon.  
  22.  
  23. What is your reason for wanting to do a different, competing OO extension of
  24. Icon?  What would it do for you that Unicon does not do already?
  25.  
  26. -----Original Message-----
  27. From: Shmuel (Seymour J.) Metz
  28. [mailto:spamtrap@library.lspace.org.invalid]
  29. Sent: Saturday, October 12, 2002 9:01 PM
  30. To: icon-group@CS.Arizona.EDU
  31. Subject: Re: Icon Wish List
  32.  
  33.  
  34.  
  35. In <aoadds$kjq8u$1@ID-79573.news.dfncis.de>, on 10/13/2002
  36.    at 12:46 AM, "Andrew Hamm" <ahamm@mail.com> said:
  37.  
  38. >I don't think you've understood what I've said. 
  39.  
  40. Au contraire; you have confirmed that I understood what I've said and
  41. that you didn't understand what I said. Typing can be static or
  42. dynamic. Icon uses dynamic typing. I never said that the association
  43. between a variable and a class should be static. I said "The class is
  44. the type.". If the type in Icon is dynamic then clearly you would
  45. expect the association of a variable to a type in a hypothetical OO
  46. Icon to also be dynamic. 
  47.  
  48. >and to me, it follows that class members should not be declared with
  49. >type either. 
  50.  
  51. Why? 
  52.  
  53. >I said "overloaded" not "overridden".
  54.  
  55. So did I.
  56.  
  57. >Since Icon supports untyped arguments,
  58.  
  59. It doesn't. It supports arguments whose type is only known at
  60. execution time. 
  61.  
  62. >it follows
  63.  
  64. No.
  65.  
  66. >Further, any method which cared to handle different args differently
  67.  
  68. Irrelevant; I'm talking about two different methods, with the choice
  69. being determined at run-time based on the classes of the parameters.
  70. That sort of thing is a basic part of the OO paradigm.
  71.  
  72. >Well, no it doesn't. You need to consider how it might be
  73. >implemented
  74.  
  75. Yes it does. I would expect some sort of hash table, which is not
  76. exactly rocket science.
  77.  
  78. >now, how can the compiler determine that arg.M is legal?
  79.  
  80. It probably can't. The run-time environment will determine it. 
  81.  
  82. >The only way to solve this is with a
  83. >runtime check which cross-references the current dynamic type with
  84. >the visibility of M in relation to the context using it. 
  85.  
  86. So what else is new?
  87.  
  88. >Did you say "Bletch!" ?
  89.  
  90. No, you did. I don't agree. There are all sorts of things that can
  91. only be checked at run time.
  92.  
  93. >I want my scripts to complete today, thank-you very much.
  94.  
  95. And I want my scripts to complete correctly, even if they take a
  96. microsecond longer.
  97.  
  98. >I am aiming more for compile-type checking.
  99.  
  100. Which is a more major change than making Icon OO.
  101.  
  102. >I spit on runtime checking
  103.  
  104. >Icon has never demanded specific declarations,
  105.  
  106. Now you've got me really confused. Which is the real Andrew; the one
  107. that wants to do the checking at compile time or the one that notices
  108. that Icon does a lot of things at run time?
  109.  
  110. >Ultimately, you have to remember that Icon is very dynamically
  111. >typed,
  112.  
  113. I remember that, but you seem to be unhappy with it.
  114.  
  115. -- 
  116.      Shmuel (Seymour J.) Metz, SysProg and JOAT
  117.      Atid/2, Team OS/2, Team PL/I
  118.  
  119. Any unsolicited commercial junk E-mail will be subject to legal
  120. action.  I reserve the right to publicly post or ridicule any
  121. abusive E-mail.
  122.  
  123. I mangled my E-mail address to foil automated spammers; reply to
  124. domain Patriot dot net user shmuel+news to contact me.  Do not
  125. reply to spamtrap@library.lspace.org
  126.  
  127.